Re: Lenovo X60 em workaround
Jack, On Sat, Jan 20, 2007 at 02:35:17PM -0800, Jack Vogel wrote: J Since this was just seen, and the patch below validated as working I J wanted J to send general email to capture this: J J The Lenovo X60 can have issues with long ping times, this is a KNOWN J hardware problem, and Intel is working with IBM/Lenovo, a final 'fix' has J not been decided on yet. Nevertheless, the patch below will work, but J I do not want to check it in as its still temporary. J J Address questions to me, J J Okay, I have a question. Could you elaborate on just what the problem is? J (I mean, since it's KNOWN and all...) I'm just having a hard time figuring J out what problem could possibly be fixed by setting the RX interrupt J delay timer to a non-zero value (especially since elsewhere in the em(4) J source it says that doing so is a Bad Thing (tm)). J J saying its known to be a problem doesnt mean its cause is known :) J They discovered that setting this eliminated the problem, but we J immediately pointed out that this is, as you pointed out, a Bad J Thing on other hardware, so the investigation continues, there is J always a communication lag on these kind of things, so I dont know J if it has been resolved yet or not. J J I just dont think this patch will become the final way to solve this, J but we shall see :) Good to know that there is progress on this. Thanks! I will try the patch on my Lenovo T60 notebook, where the problem is also present. AFAIK, it is present on any Lenovo notebook with 82573 NIC. Can you please acknowledge that another bug with Lenovo + em(4) is known? I mean the problem, that em(4) isn't initialized properly on kernel boot, if the link is down. I have already reported this to you, and you said that I probably have bad hardware. Since that time, I've found several similar reports about Lenovo notebooks and em(4) driver in FreeBSD. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPv6 over gif(4) broken in 6.2-RELEASE?
Bruce A. Mah wrote: and later I found out it was caused by commit 1.48.2.16: http://lists.freebsd.org/pipermail/freebsd-stable/2006-December/031853.html This isn't consistent with what I'm finding. For one thing, rev. 1.48.2.16 of nd6.c isn't in 6.2-RELEASE but I saw the problem there anyways. Also, that's not the change I made to my local sources to get my gif(4) tunnel working. Are you sure about this? :-) I'm following -STABLE, and 1.48.2.16 is in there. Since it was committed on 29 Nov, I suspected it would end up in -RELEASE, but apparently not. :) I explicitly tried reverting just this one commit, and for me it solved the problem (i.e. the automagical addition of needed routing entries). So for you, reverting the combination of 1.48.2.14 and .15 works? Maybe there is something else involved too, for example the route command itself? I'll have to experiment a bit further, I guess. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fatal trap while configuring re0 (Realtek 8136)
* Pyun YongHyeon [EMAIL PROTECTED] wrote: How about attached one? I cannot test that at this moment. There is no free partition to install freebsd to (that's why I tried a LiveCD first). I'll try to get an empty hdd and test it. Thanks. -- By(t)e, Stefan 'Steve' Tell | http://blog.crashmail.de ---| http://www.freebsd.org Powered by FreeBSD/i386| http://www.naturefund.de ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPv6 problems with 6.2-RELEASE ?
If memory serves me right, Pete French wrote: 2) rtsol(8) is used to initiate stateless autoconfiguration. You might=20 want to try rtsol -d interface. Aha... this does not work... 3) Check the net.inet6.ip6.accept_rtadv sysctl. ipv6_enable should take=20 care of this. ...because this is 0 All of which appears to be because a spurious 'ipv6_gateway_enable=YES' has found it's way into my rc.conf due to cut-n-paste. Which is interesting though, since even when I spotted it, it hadn;'t occurred to me that it would prevent the auto configuration working. Ah yes, I remember stumbling over this (or some similar problem) many years ago. Machines that are configured as routers/gateways, as well as multi-homed end-hosts, aren't supposed to use rtsol. Also, accept_rtadv is usually 0...I think that our IPv6 startup scripts toggle it to 1 just long enough to get a route advertisement and then set it back to 0. Bruce. signature.asc Description: OpenPGP digital signature
Re: Lenovo X60 em workaround
On 1/22/07, Gleb Smirnoff [EMAIL PROTECTED] wrote:
Jack,
On Sat, Jan 20, 2007 at 02:35:17PM -0800, Jack Vogel wrote:
J Since this was just seen, and the patch below validated as working I
J wanted
J to send general email to capture this:
J
J The Lenovo X60 can have issues with long ping times, this is a KNOWN
J hardware problem, and Intel is working with IBM/Lenovo, a final 'fix' has
J not been decided on yet. Nevertheless, the patch below will work, but
J I do not want to check it in as its still temporary.
J
J Address questions to me,
J
J Okay, I have a question. Could you elaborate on just what the problem is?
J (I mean, since it's KNOWN and all...) I'm just having a hard time figuring
J out what problem could possibly be fixed by setting the RX interrupt
J delay timer to a non-zero value (especially since elsewhere in the em(4)
J source it says that doing so is a Bad Thing (tm)).
J
J saying its known to be a problem doesnt mean its cause is known :)
J They discovered that setting this eliminated the problem, but we
J immediately pointed out that this is, as you pointed out, a Bad
J Thing on other hardware, so the investigation continues, there is
J always a communication lag on these kind of things, so I dont know
J if it has been resolved yet or not.
J
J I just dont think this patch will become the final way to solve this,
J but we shall see :)
Good to know that there is progress on this. Thanks! I will try the patch
on my Lenovo T60 notebook, where the problem is also present. AFAIK, it
is present on any Lenovo notebook with 82573 NIC.
Can you please acknowledge that another bug with Lenovo + em(4) is known? I
mean the problem, that em(4) isn't initialized properly on kernel boot, if
the link is down. I have already reported this to you, and you said that
I probably have bad hardware. Since that time, I've found several similar
reports about Lenovo notebooks and em(4) driver in FreeBSD.
Hey Gleb,
Acknowledge... I can do better than that, I have a fix for this problem, and
its not temporary. Here is the code change (not a patch, I'm very busy),
its in hardware_init, should be obvious how to patch:
/* Make sure we have a good EEPROM before we read from it */
if (e1000_validate_nvm_checksum(adapter-hw) 0) {
/*
** Some PCI-E parts fail the first check due to
** the link being in sleep state, call it again,
** if it fails a second time its a real issue.
*/
if (e1000_validate_nvm_checksum(adapter-hw) 0) {
device_printf(dev,
The EEPROM Checksum Is Not Valid\n);
return (EIO);
}
}
This is already checked into my code base at Intel, I've just been too
busy to do anything with it, be my guest if you wish to check it in after
testing...
Cheers,
Jack
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Lenovo X60 em workaround
On 1/22/07, Jack Vogel [EMAIL PROTECTED] wrote:
On 1/22/07, Gleb Smirnoff [EMAIL PROTECTED] wrote:
Jack,
On Sat, Jan 20, 2007 at 02:35:17PM -0800, Jack Vogel wrote:
J Since this was just seen, and the patch below validated as working I
J wanted
J to send general email to capture this:
J
J The Lenovo X60 can have issues with long ping times, this is a KNOWN
J hardware problem, and Intel is working with IBM/Lenovo, a final 'fix'
has
J not been decided on yet. Nevertheless, the patch below will work, but
J I do not want to check it in as its still temporary.
J
J Address questions to me,
J
J Okay, I have a question. Could you elaborate on just what the problem is?
J (I mean, since it's KNOWN and all...) I'm just having a hard time figuring
J out what problem could possibly be fixed by setting the RX interrupt
J delay timer to a non-zero value (especially since elsewhere in the em(4)
J source it says that doing so is a Bad Thing (tm)).
J
J saying its known to be a problem doesnt mean its cause is known :)
J They discovered that setting this eliminated the problem, but we
J immediately pointed out that this is, as you pointed out, a Bad
J Thing on other hardware, so the investigation continues, there is
J always a communication lag on these kind of things, so I dont know
J if it has been resolved yet or not.
J
J I just dont think this patch will become the final way to solve this,
J but we shall see :)
Good to know that there is progress on this. Thanks! I will try the patch
on my Lenovo T60 notebook, where the problem is also present. AFAIK, it
is present on any Lenovo notebook with 82573 NIC.
Can you please acknowledge that another bug with Lenovo + em(4) is known? I
mean the problem, that em(4) isn't initialized properly on kernel boot, if
the link is down. I have already reported this to you, and you said that
I probably have bad hardware. Since that time, I've found several similar
reports about Lenovo notebooks and em(4) driver in FreeBSD.
Hey Gleb,
Acknowledge... I can do better than that, I have a fix for this problem, and
its not temporary. Here is the code change (not a patch, I'm very busy),
its in hardware_init, should be obvious how to patch:
/* Make sure we have a good EEPROM before we read from it */
if (e1000_validate_nvm_checksum(adapter-hw) 0) {
/*
** Some PCI-E parts fail the first check due to
** the link being in sleep state, call it again,
** if it fails a second time its a real issue.
*/
if (e1000_validate_nvm_checksum(adapter-hw) 0) {
device_printf(dev,
The EEPROM Checksum Is Not Valid\n);
return (EIO);
}
}
This is already checked into my code base at Intel, I've just been too
busy to do anything with it, be my guest if you wish to check it in after
testing...
Cheers,
Jack
LOL, opps, I just realized, this code reflects the new shared code
that I am in the process of releasing, in order for this to work in
6.2 change 'e1000_validate_nvm_checksum' to
'em_validate_eeprom_checksum' and all should be clear :)
Jack
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fatal trap while configuring re0 (Realtek 8136)
* Pyun YongHyeon [EMAIL PROTECTED] wrote: On Sun, Jan 21, 2007 at 06:36:00PM +0100, Stefan 'Steve' Tell wrote: [EMAIL PROTECTED]:0:0: class=0x02 card=0x105317c0 chip=0x813610ec rev=0x01 hdr=0x00 class = network subclass = ethernet [EMAIL PROTECTED]:0:0: class=0x028000 card=0x10018086 chip=0x42228086 rev=0x02 hdr=0x00 class = network How about attached one? Very cool, it works. I've brought the device up and dhclient re0 get's an IP from my router. Very nice and many thanks for this. There are some new ACPI-1304-warnings now. I'll post them later to this mailinglist. -- By(t)e, Steve /\ http://www.crashmail.de GnuPG/PGP: 0x9B6C7E15, encrypted mail prefered, see header ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BTX issues when booting from a USB CD-ROM
On Sun, 21 Jan 2007 23:39:02 + Bruce M. Simpson [EMAIL PROTECTED] wrote: Peter Losher wrote: In both cases, once the USB CD-ROM started loading either 6.1 or 6.2, I get a BTX halt: Known issue. The btx code can't deal with BIOSes which want to enter protected mode to service the I/Os. USB support in most BIOSen generally does this. Aha. So on a laptop I have where booting FreeBSD from a usb harddrive results in endless scrolling of text on the console (probably register dumps, hard to tell) until the laptop is turned off, this might be the same issue? I can boot NetBSD and OpenBSD from different partitions on the same usb hardrive, on the same laptop. Is there a known fix or workaround for this issue? (Probably not, but just in case...) -- Regards, Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BTX issues when booting from a USB CD-ROM
On Mon, Jan 22, 2007 at 07:46:31PM +0100, Torfinn Ingolfsen wrote: Aha. So on a laptop I have where booting FreeBSD from a usb harddrive results in endless scrolling of text on the console (probably register dumps, hard to tell) until the laptop is turned off, this might be the same issue? I can boot NetBSD and OpenBSD from different partitions on the same usb hardrive, on the same laptop. Is there a known fix or workaround for this issue? (Probably not, but just in case...) Does the GRUB bootloader behave this way? If not (e.g. it works), then one could use that as an alternative to btx. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel panic on 6.2-RC2 with GENERIC.
On Monday, 22 January 2007 at 14:22:29 +0800, erich wrote:
Dear Nikolay Pavlov,
Please update your RAID adapter firmware's version into 1.42.
I the problem still there please tell me again.
I am trying to reproduce this bug in my lab,
but till now I can not reproduce it.
No luck, sir. After upgrade to 1.42 it's still very unstable:
# kgdb kernel.debug /mnt/mnt2/crash/vmcore.5
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
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 i386-marcel-freebsd.
Unread portion of the kernel message buffer:
panic: softdep_deallocate_dependencies: dangling deps
Uptime: 5m11s
Dumping 3583 MB (2 chunks)
chunk 0: 1MB (156 pages) ... ok
chunk 1: 3583MB (917216 pages) 3567 3551 3535 3519 3503 3487 3471 3455 3439
3423 3407 3391 3375 3359 3343 3327 3311 3295 3279 3263 3247 3231 3215 3199 3183
3167 3151 3135 3119 3103 3087 3071 3055 3039 3023 3007 2991 2975 2959 2943 2927
2911 2895 2879 2863 2847 2831 2815 2799 2783 2767 2751 2735 2719 2703 2687 2671
2655 2639 2623 2607 2591 2575 2559 2543 2527 2511 2495 2479 2463 2447 2431 2415
2399 2383 2367 2351 2335 2319 2303 2287 2271 2255 2239 2223 2207 2191 2175 2159
2143 2127 2111 2095 2079 2063 2047 2031 2015 1999 1983 1967 1951 1935 1919 1903
1887 1871 1855 1839 1823 1807 1791 1775 1759 1743 1727 1711 1695 1679 1663 1647
1631 1615 1599 1583 1567 1551 1535 1519 1503 1487 1471 1455 1439 1423 1407 1391
1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 1183 1167 1151 1135
1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 911 895 879 863 847
831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591 575 559 543 527
511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 271 255 239 223 207
191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:165
165 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:165
#1 0xc067005a in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409
#2 0xc06702f0 in panic (fmt=0xc08e0219 softdep_deallocate_dependencies:
dangling deps) at /usr/src/sys/kern/kern_shutdown.c:565
#3 0xc079dc2e in softdep_deallocate_dependencies (bp=0x0) at
/usr/src/sys/ufs/ffs/ffs_softdep.c:6255
#4 0xc06b73e3 in getnewbuf (slpflag=0, slptimeo=0, size=16384, maxsize=16384)
at buf.h:447
#5 0xc06b88dc in getblk (vp=0xcd2b2330, blkno=2115, size=16384, slpflag=0,
slptimeo=0, flags=1) at /usr/src/sys/kern/vfs_bio.c:2497
#6 0xc06bc9b3 in cluster_rbuild (vp=0xcd2b2330, filesize=50608376, lbn=2113,
blkno=1819849504, size=16384, run=8, fbp=0x0)
at /usr/src/sys/kern/vfs_cluster.c:374
#7 0xc06bc607 in cluster_read (vp=0xcd2b2330, filesize=50608376, lblkno=2113,
size=16384, cred=0x0, totread=4096, seqcount=127, bpp=0x0)
at /usr/src/sys/kern/vfs_cluster.c:252
#8 0xc07a234b in ffs_read (ap=0x0) at /usr/src/sys/ufs/ffs/ffs_vnops.c:503
#9 0xc086f924 in VOP_READ_APV (vop=0x0, a=0x0) at vnode_if.c:643
#10 0xc06d4209 in vn_read (fp=0xc9bbe3a8, uio=0xec89bcbc,
active_cred=0xccde6a00, flags=0, td=0xcba86480) at vnode_if.h:343
#11 0xc0691e0d in dofileread (td=0xcba86480, fd=5, fp=0xc9bbe3a8,
auio=0xec89bcbc, offset=Unhandled dwarf expression opcode 0x93
) at file.h:240
#12 0xc0691ca6 in kern_readv (td=0xcba86480, fd=5, auio=0xec89bcbc) at
/usr/src/sys/kern/sys_generic.c:192
#13 0xc0691bd1 in read (td=0xcba86480, uap=0x0) at
/usr/src/sys/kern/sys_generic.c:116
#14 0xc085e9f7 in syscall (frame=
{tf_fs = 59, tf_es = -1078001605, tf_ds = -1078001605, tf_edi = 8192,
tf_esi = 672845424, tf_ebp = -1077951544, tf_isp = -326517404, tf_ebx =
672769032, tf_edx = 0, tf_ecx = 1, tf_eax = 3, tf_trapno = 32, tf_err = 2,
tf_eip = 672715519, tf_cs = 51, tf_eflags = 530, tf_esp = -1077951572, tf_ss =
59})
at /usr/src/sys/i386/i386/trap.c:983
#15 0xc084d0cf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:200
#16 0x0033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
Best Regards
Erich Chen
- Original Message -
From: Nikolay Pavlov [EMAIL PROTECTED]
To: freebsd-stable@freebsd.org
Sent: Saturday, January 06, 2007 12:59 AM
Subject: kernel panic on 6.2-RC2 with GENERIC.
Hello folks.
I have kernel panic on GENERIC kernel while executing postmark.
Before panic there were messages like this:
g_vfs_done():da1s1d[WRITE(offset=772363010048, length=16384)]error = 5
g_vfs_done():da1s1d[WRITE(offset=772363026432, length=16384)]error = 5
g_vfs_done():da1s1d[WRITE(offset=772363042816, length=16384)]error = 5
g_vfs_done():da1s1d[WRITE(offset=772363059200, length=16384)]error = 5
and
Re: BTX issues when booting from a USB CD-ROM
On Mon, 22 Jan 2007 10:54:33 -0800 Jeremy Chadwick [EMAIL PROTECTED] wrote: Does the GRUB bootloader behave this way? If not (e.g. it works), then one could use that as an alternative to btx. Don't know, I haven't tested it. I have tested the NetBSD boot loader, and it behaves in the same way as the FreeBSD boot loader. Like this: (FreeBSD, NetBSD and OpenBSD installed on different partitions on the same usb hard drive. Using F12 on laptop bootup to get a boot menu, then selecting the usb hard drive, whivj brings up the boot loader on that usb hard drive) FreeBSD boot loader: boots NetBSD, OpenBSD, but not FreeBSD NetBSD boot loader: boots NetBSD, OpenBSD, but not FreeBSD See messages with the subject Install FreeBSD on an external (usb) hard drive? in the archives of freebsd-mobile for more information. I hope I don't need to test grub. Everytime I try it, I end up having to recover something (probably my fault). I'm really not comfortable with grub. -- Regards Torfinn Ingolfsen, Norway ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: any real documentation of the boot2 prompt?
On Jan 21, 2007, at 1:40 AM, Steve Watt wrote: In [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: Václav Haisman wrote: What does lsdev or whatever it was say? Does it show any devices besides the raw disks? So I booted from CD and ran lsdev, and showed something like this (from memory) 0: Drive A 2: Disk 0 1: FFS You need to get into your SCSI BIOS (don't know what the key sequence is for 3ware, it's ^A for Adaptec) at the correct time and enable the disk for booting. As shown here, there's no chance of it being bootable. Thanks, but I didn't need any help with the SCSI BIOS. The question was only how to determine what devices are visible to FreeBSD. Apparently 3ware only shows a single LUN to the BIOS, even when it shows multiple LUNs to the booted system. -- Jo Rhett senior geek Silicon Valley Colocation ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.2 Release - Adaptec 2130SLP driver?? issue - aac driver
On Jan 20, 2007, at 2:06 AM, LI Xin wrote: My newer 2230SLP cards do not work with any extant command line tools for freebsd under amd64. The older cards did. I've tested FreeBSD 6.0 and 6.1. 6.2 is on the agenda to test soon. Do you mean Linux CLI tools on FreeBSD? I think I have missed my src/sys/dev/aac/aac_linux.c,v 1.4 change with re@ so I think there might be no change. Just MFC'ed that to RELENG_6. The linux tools have 0 chance of working on amd64 I have some newer version from one of the freebsd devs of adaptec CLI but it doesn't recognize the latest firmware in the 2230 card. I've been trying to work with that developer to sponsor some work to make the tools available and working on newer hardware and FreeBSD versions, but there has been some hold up getting necessary bits out of Adaptec.
Re: BTX issues when booting from a USB CD-ROM
Torfinn Ingolfsen wrote: I hope I don't need to test grub. Everytime I try it, I end up having to recover something (probably my fault). I'm really not comfortable with grub. Until the btx code is rewritten to deal with BIOS routines which expect to be run from within real mode and not vm86 mode, GRUB is probably the most convenient workaround for the issue. Regards, BMS ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Cannot start install cd of 6.2-R at all
Artem Kuchin wrote: Mark Kirkwood wrote: I have seen this with a Tyan PIII board + TX2000. In my case re-trying the boot from cd several times would *eventually* get a working installer session. (If you search the archives you'll see several cases of folks encountering this). Unfortunately I don't know of any solution. A (tedious) workaround (in case repeated attempts always fail for you), is to install a minimal system off an earlier version of FreeBSD and run the installer off the installed system - or just src upgrade to the version you want. I found that the 4.x, 5.0, 5.1 and 5.2 cd's all worked fine - but 5.3 onwards and 6.x would register dump. There is a better workaround which i used. A simple start of installer from 4 floppies. Then install the whole system from CD-ROM. It does work but insolved copying of floppy images onto the disks. However is it a very annoying problem which i have been encountering since 5.0-RELEASE. The bootloader failed when trying to load installed from CD-ROM on pretty much every PIII and old Celeron pc which i tried. (it is about 6 machines by now). Very weird and i have no idea to how help to solve the problem. Right, however it means you need a floppy drive - and I've gone floppiless for my machines... :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Sony GC89 edge/gprs card
Does anyone know if it is possible to get the Sony Ericsson GC89 EDGE/GPRS PC Card working in FreeBSD, I can't find any references in the release or hardware notes, but there are some tantalizing hints when I Google it that there is support, but nothing concrete, and definitely no how to's. If anyome has got it working, what drivers were used? Thanks Jeff ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fatal trap while configuring re0 (Realtek 8136)
On Mon, Jan 22, 2007 at 06:21:33PM +0100, Stefan 'Steve' Tell wrote: * Pyun YongHyeon [EMAIL PROTECTED] wrote: On Sun, Jan 21, 2007 at 06:36:00PM +0100, Stefan 'Steve' Tell wrote: [EMAIL PROTECTED]:0:0: class=0x02 card=0x105317c0 chip=0x813610ec rev=0x01 hdr=0x00 class = network subclass = ethernet [EMAIL PROTECTED]:0:0: class=0x028000 card=0x10018086 chip=0x42228086 rev=0x02 hdr=0x00 class = network How about attached one? Very cool, it works. I've brought the device up and dhclient re0 get's an IP from my router. Very nice and many thanks for this. Committed(if_re.c rev, 1.83). MFC after 1 week. Thanks for the report and testing. There are some new ACPI-1304-warnings now. I'll post them later to this mailinglist. -- By(t)e, Steve /\ http://www.crashmail.de GnuPG/PGP: 0x9B6C7E15, encrypted mail prefered, see header -- 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]
Re: 6.2 Release - Adaptec 2130SLP driver?? issue - aac driver
On Mon, Jan 22, 2007 at 03:01:13PM -0500, Vivek Khera wrote: On Jan 20, 2007, at 2:06 AM, LI Xin wrote: My newer 2230SLP cards do not work with any extant command line tools for freebsd under amd64. The older cards did. I've tested FreeBSD 6.0 and 6.1. 6.2 is on the agenda to test soon. The linux tools have 0 chance of working on amd64 I have some newer version from one of the freebsd devs of adaptec CLI but it doesn't recognize the latest firmware in the 2230 card. Sigh. Okay, thank you for the responses. I think I will go with Plan 'C', and find a PCI-X LSI MegaRAID card. I think there is some hope the megamgr port will work with them. Bruce -- I like bad! Bruce BurdenAustin, TX. - Thuganlitha The Power and the Prophet Robert Don Hughes ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
(no subject)
... 54netkey 2007-01-23 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
System hang on laptop suspend/resume
[Working my way up the food chain here after no response on freebsd-questions and freebsd-mobile. Please tell me if this question is ill-formed or if the answer is unlikely to be known.] I was running FreeBSD 4.8 on my Sony PCG-505TR laptop for about three years until I recently upgraded to 6.1 with a clean install on a new disk drive. One aspect of FreeBSD that I really liked was that suspend-to-memory and resume worked perfectly and quickly every time, whereas when I had previously tried this with Windows it usually failed. I did not even need to run apmd or configure any suspend or resume scripts other than the normal configuration in pccard.conf for the an0 802.11 network card. Sadly, with FreeBSD 6.1, the result is often a system hang requiring a power cycle to recover. I have found that I can avoid the hang if I do two things before suspend: - switch the display from X to the console vty (which I have automated using vidcontrol as suggested in the laptop article) - manually unplug the 802.11 network card and wait for dhclient to exit before suspending, and leave the card unplugged until after resuming My question is this: How can I programmatically power down or detach the network card? ifconfig an0 down is not sufficient. I'm worried about wearing out my PC Card slot by frequently unplugging the card. On 4.8, I used pccardc power 0 0 to power down the card, but on 6.1 it results in the error message: pccardc: /dev/card0: No such file or directory In the mail archive, I saw that pccardc is not supported in NEWCARD, but the binary and man page are still included in the 6.1 release. Or is there something else I should be doing instead? Here are additional details -- - This laptop BIOS supports APM but not ACPI. - I am running apmd and have it configured to invoke rc.suspend and rc.resume, which in turn run vidcontrol. - I have two network cards: an0 and ath0. For an0, the hang occurs on resume about half the time. With ath0, it aways hangs. - The hang is indicated by a timeout on ad0 (see below). At that point, I can switch vtys among 1-8, but going to vty9 (X server) will hang. Ctrl-Alt-Delete does nothing. Return just echoes return, no login prompt (will echo more than once). - Pulling Aironet card and replugging results in: Interrupt storm detected on irq9:; throttling interrrupt source Messages on the console vty (manually copied): Dec 2 00:57:56 kao root: Received USERSUSPENDREQ Dec 2 00:57:56 kao apm: suspend an0: detached Dec 2 14:32:20 kao root: Received NORMRESUME Dec 2 14:32:20 kao apm: resumed from suspend Dec 2 14:32:20 kao dhclient[3365]: send_packet: Device not configured an0: Cisco Systems 340 Series Wireless LAN Adapter at port 0x100-0x13f irq 9 function 0 config 5 on pccard0 an0: got RSSI - dBM map an0: supported rates: 1Mbps 2Mbps 5.5Mbps 11Mbps an0: Ethernet address: 00:40:96:32:05:b7 an0: [GIANT-LOCKED] ad0: TIMEOUT - READ_DMA retrying (1 retry left) LBA=68041200 Messages from /var/log/messages: Dec 2 00:57:56 kao apmd[412]: apmevent 000a index 7 Dec 2 00:57:56 kao root: Received USERSUSPENDREQ Dec 2 00:57:56 kao apm: suspend Dec 2 14:32:20 kao kernel: an0: detached Dec 2 14:32:20 kao kernel: wakeup from sleeping state (slept 13:34:17) Dec 2 14:32:19 kao apmd[412]: apmevent 0003 index 8 Dec 2 14:32:20 kao root: Received NORMRESUME Dec 2 14:32:20 kao apm: resumed from suspend Dec 2 14:32:20 kao dhclient[3365]: send_packet: Device not configured Dec 2 14:54:13 kao syslogd: kernel boot file is /boot/kernel/kernel Note that some log messages are written after resuming and before the hang, so ad0 is working up to the point where it gets the timeout. -- Steve ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
