Re: [releng_4_8 tinderbox] failure on i386/i386
FreeBSD Tinderbox [EMAIL PROTECTED] writes: TB --- 2005-02-06 15:45:26 - tinderbox 2.3 running on dwp.des.no Ack! This was a test run, I didn't intend for mail to go out but forgot to change the rc file. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [releng_4_8 tinderbox] failure on i386/i386
On Mon, Feb 07, 2005 at 09:00:38AM +0100, Dag-Erling Sm?rgrav wrote: FreeBSD Tinderbox [EMAIL PROTECTED] writes: TB --- 2005-02-06 15:45:26 - tinderbox 2.3 running on dwp.des.no Ack! This was a test run, I didn't intend for mail to go out but forgot to change the rc file. It's okay, no-one reads these mails any more anyway :-) Kris pgpBVmyvFRllI.pgp Description: PGP signature
Re: 50% of packets lost only on local interfaces
José M. Fandiño wrote: Chris wrote: Have tested on 3 boxes. yes, it's the intended operation and If I don't see it I don't believe it but it happens. I ever thought it would be possible. Finally, I found the culprit: CFLAGS= \ 100% of the transmited traffic is received COPTFLAGS= / CFLAGS= -pipe \ 50% of the transmited traffic is received COPTFLAGS= -pipe / CFLAGS= -O -pipe \ 100% of the transmited traffic is received COPTFLAGS= -O -pipe / The weirdest is that it worked in 5.3-RELEASE and some time later, whilst I was tracking -stable, aplications began to fail local network conections. Simple tests with ping showed me as the kernel receive packets (tcpdump seems to see inbound packets) but ignores exacly 50% of them. This makes any sense to someone? Following the proposed solution for kern/72022 I removed /usr/obj, all possible harmful options in make.conf and compiled world and a GENERIC kernel again without any luck. grep '^[^#]' /etc/make.conf CFLAGS= -pipe COPTFLAGS= -pipe NOPROFILE= true# Avoid compiling profiled libraries X_WINDOW_SYSTEM=xorg PERL_VER=5.8.5 PERL_VERSION=5.8.5 PERL_ARCH=mach NOPERL=yo NO_PERL=yo NO_PERL_WRAPPER=yo SENDMAIL_CFLAGS=-I/usr/local/include -DSTARTTLS -DSASL=2 -DMILTER -DLDAPMAP SENDMAIL_LDFLAGS= -L/usr/local/lib SENDMAIL_LDADD=-lsasl2 -lssl -lcrypto -lldap -llber I'm lost here, any help will be welcome. Regards, 5.3-STABLE compiled Jan 5th --- 127.0.0.1 ping statistics --- 61 packets transmitted, 61 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.062/0.073/0.146/0.013 ms 5.3-STABLE amd64 build compiled Jan 29th --- 127.0.0.1 ping statistics --- 60 packets transmitted, 60 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.024/0.030/0.048/0.005 ms 5.3-Release-P5 --- 127.0.0.1 ping statistics --- 60 packets transmitted, 60 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.057/0.089/0.167/0.017 ms On Mon, 31 Jan 2005 19:12:52 +0100, José M. Fandiño [EMAIL PROTECTED] wrote: Hello, It sounds weird but tcp/ip traffic directed to _local_ interfaces, and only _local_ interfaces, always cause 50% of packets lost. Of course there isn't packet filters activated. I'm running -stable (the last update was this past weekend) There is another report like this: http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/72022 but the suggested solution doesn't works in my case. ping to local interfaces get replies for 50% of the packets: ping -c 512 127.0.0.1 [snip] --- 127.0.0.1 ping statistics --- 512 packets transmitted, 257 packets received, 49% packet loss round-trip min/avg/max/stddev = 0.046/0.049/0.077/0.004 ms ping -c 512 10.20.30.2 [snip] --- 10.20.30.2 ping statistics --- 512 packets transmitted, 254 packets received, 50% packet loss round-trip min/avg/max/stddev = 0.017/0.049/0.071/0.004 ms Also running tcpdump on localhost shows as the kernel stop from responding to packets without an apparent motive. tcpdump -n -i lo0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo0, link-type NULL (BSD loopback), capture size 96 bytes [snip] 17:58:15.516451 IP 127.0.0.1 127.0.0.1: icmp 64: echo request seq 76 17:58:15.516476 IP 127.0.0.1 127.0.0.1: icmp 64: echo reply seq 76 17:58:16.517321 IP 127.0.0.1 127.0.0.1: icmp 64: echo request seq 77 17:58:16.517347 IP 127.0.0.1 127.0.0.1: icmp 64: echo reply seq 77 17:58:17.518158 IP 127.0.0.1 127.0.0.1: icmp 64: echo request seq 78 17:58:18.519042 IP 127.0.0.1 127.0.0.1: icmp 64: echo request seq 79 17:58:19.519853 IP 127.0.0.1 127.0.0.1: icmp 64: echo request seq 80 17:58:20.520698 IP 127.0.0.1 127.0.0.1: icmp 64: echo request seq 81 17:58:21.521548 IP 127.0.0.1 127.0.0.1: icmp 64: echo request seq 82 17:58:22.522392 IP 127.0.0.1 127.0.0.1: icmp 64: echo request seq 83 more tests, to the lan router: ping -c 500 10.20.30.6 [snip] --- 10.20.30.6 ping statistics --- 500 packets transmitted, 500 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.565/2.015/40.189/2.385 ms from the lan router: Router#ping Protocol [ip]: Target IP address: 10.20.30.2 Repeat count [5]: 500 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 500, 100-byte ICMP Echos to 10.20.30.2, timeout is 2 seconds: !! !! !!!.!! !! !!
Re: 50% of packets lost only on local interfaces
On Mon, Feb 07, 2005 at 11:15:52AM +0100, Jos? M. Fandi?o wrote: Jos? M. Fandi?o wrote: Chris wrote: Have tested on 3 boxes. yes, it's the intended operation and If I don't see it I don't believe it but it happens. I ever thought it would be possible. Finally, I found the culprit: CFLAGS= \ 100% of the transmited traffic is received COPTFLAGS= / CFLAGS= -pipe \ 50% of the transmited traffic is received COPTFLAGS= -pipe / That would be exceedingly strange, because the above two options are supposed to produce *no differences at all* with the code generation. I'd believe that -O and no -O could behave differently, although I don't know why you'd want to compile without -O. Kris pgpt7CQHgFsCG.pgp Description: PGP signature
Re: 50% of packets lost only on local interfaces
Kris Kennaway wrote: On Mon, Feb 07, 2005 at 11:15:52AM +0100, Jos? M. Fandi?o wrote: Jos? M. Fandi?o wrote: Chris wrote: Have tested on 3 boxes. yes, it's the intended operation and If I don't see it I don't believe it but it happens. I ever thought it would be possible. Finally, I found the culprit: CFLAGS= \ 100% of the transmited traffic is received COPTFLAGS= / CFLAGS= -pipe \ 50% of the transmited traffic is received COPTFLAGS= -pipe / That would be exceedingly strange, because the above two options are supposed to produce *no differences at all* with the code generation. I'd believe that -O and no -O could behave differently, although I don't know why you'd want to compile without -O. because by the time I was compiling the system I was no interested in compiler optimizations. Now I prefer a lightly optimized kernel than a system with 50% of packet lost in local interfaces ;-) -- -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS/IT d- s+:+() a- C+++ UBL+++$ P+ L+++ E--- W++ N+ o++ K- w--- O+ M+ V- PS+ PE+ Y++ PGP t+ 5 X+$ R- tv-- b+++ DI D+ G++ e- h+(++) !r !z --END GEEK CODE BLOCK-- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA mkIII first official patches - please test!
After suspend, my ThinkPad X40 now hangs with following logs (copied by hand): Hmm, do you have ATA compiled in or as modules. I could easily imagine that modules could have problems, but as built in nothing really changed... my patched t41, current with ata in the kernel, locks up with disk light on solid on resume. randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA mkIII first official patches - please test!
Randy Bush wrote: After suspend, my ThinkPad X40 now hangs with following logs (copied by hand): Hmm, do you have ATA compiled in or as modules. I could easily imagine that modules could have problems, but as built in nothing really changed... my patched t41, current with ata in the kernel, locks up with disk light on solid on resume. Does it work with stock ATA ? I cant work on suspend/resume as it has been broken due to ACPI brokenness since september last year on all my laptops... -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA mkIII first official patches - please test!
my patched t41, current with ata in the kernel, locks up with disk light on solid on resume. Does it work with stock ATA ? it did last week, before i rebuilt with patch I cant work on suspend/resume as it has been broken due to ACPI brokenness since september last year on all my laptops... yep. been there, have the tee-shirt randy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA mkIII first official patches - please test!
Sren Schmidt [EMAIL PROTECTED] writes: Randy Bush wrote: After suspend, my ThinkPad X40 now hangs with following logs (copied by hand): Hmm, do you have ATA compiled in or as modules. I could easily imagine that modules could have problems, but as built in nothing really changed... my patched t41, current with ata in the kernel, locks up with disk light on solid on resume. Does it work with stock ATA ? I cant work on suspend/resume as it has been broken due to ACPI brokenness since september last year on all my laptops... Same here, worked before the patch. Does not work with the patch. Arne -- compiling millions of tiny c-programs...done checking for a working configure script... not found ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA mkIII first official patches - please test!
Arne Schwabe wrote:
Sren Schmidt [EMAIL PROTECTED] writes:
Randy Bush wrote:
After suspend, my ThinkPad X40 now hangs with following logs (copied
by hand):
Hmm, do you have ATA compiled in or as modules. I could easily
imagine that modules could have problems, but as built in nothing
really changed...
my patched t41, current with ata in the kernel, locks up with disk
light on solid on resume.
Does it work with stock ATA ?
I cant work on suspend/resume as it has been broken due to ACPI
brokenness since september last year on all my laptops...
Same here, worked before the patch. Does not work with the patch.
Hmm, the attached patch is the only real difference, which actually
shouldn't pose a problem (and fixes broken APM)..
Let me know if that changes anything, other than that you are free to
bug the ACPI gang to make ACPI work on the HW I have available for
development...
-Sren
diff -u -r1.20 ata-all.c
--- ata-all.c 2005/02/03 17:02:31 1.20
+++ ata-all.c 2005/02/07 14:27:57
@@ -630,7 +630,7 @@
void
ata_udelay(int interval)
{
-if (1 || interval (100/hz) || ata_delayed_attach)
+if (interval (100/hz) || ata_delayed_attach)
DELAY(interval);
else
tsleep(interval, PRIBIO, ataslp, interval/(100/hz));
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA mkIII first official patches - please test!
diff -u -r1.20 ata-all.c
--- ata-all.c 2005/02/03 17:02:31 1.20
+++ ata-all.c 2005/02/07 14:27:57
@@ -630,7 +630,7 @@
void
ata_udelay(int interval)
{
-if (1 || interval (100/hz) || ata_delayed_attach)
+if (interval (100/hz) || ata_delayed_attach)
DELAY(interval);
else
tsleep(interval, PRIBIO, ataslp, interval/(100/hz));
no fix
hangs in ad0: TIMEOUT - WRITE DMA retrying (2 retries left) LBA=7434015
disk light on solid. no response to anything
randy
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA mkIII first official patches - please test!
Randy Bush wrote:
diff -u -r1.20 ata-all.c
--- ata-all.c 2005/02/03 17:02:31 1.20
+++ ata-all.c 2005/02/07 14:27:57
@@ -630,7 +630,7 @@
void
ata_udelay(int interval)
{
-if (1 || interval (100/hz) || ata_delayed_attach)
+if (interval (100/hz) || ata_delayed_attach)
DELAY(interval);
else
tsleep(interval, PRIBIO, ataslp, interval/(100/hz));
no fix
hangs in ad0: TIMEOUT - WRITE DMA retrying (2 retries left) LBA=7434015
disk light on solid. no response to anything
no idea
Since I cannot debug this, I have no way of finding out whats wrong.
I will look at it when ACPI allows me to use suspend/resume again, until
then I'll concentrated on things that I can work on...
--
-Søren
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA mkIII first official patches - please test!
Randy Bush wrote: Since I cannot debug this, I have no way of finding out whats wrong. I will look at it when ACPI allows me to use suspend/resume again, until then I'll concentrated on things that I can work on... where's my refund? :-) more seriously, shall we do a fund to get you a laptoy on which acpi happens to work this week? Find such a machine might be very hard, if not plain impossible :/ I already have 3 laptops here (of which none has worked for several month regarding suspend/resume) so I have plenty. However getting laptops to those thats supposed to maintain ACPI might be an idea, but we should make certain that it would help first ;) -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: machine locks with PF (without using user dependent rules)
Am Samstag, 8. Januar 2005 18:24 schrieb Max Laier:
On Saturday 08 January 2005 17:52, Robert Watson wrote:
On Sat, 8 Jan 2005, Harald Schmalzbauer wrote:
my machine hard locks with the attached ruleset. If I set
debug.mpsafenet to 0 everything is fine. This was a wild guess from me,
I could nowhere find the info that PF needs this tweaking and I think
it's not intended, otherwise it would be done in rc.conf e.g.
Yes, it is not intended. Please keep in mind that debug.mpsafenet cannot
be alterted at runtime, hence rc.conf would be too late anyway. Just
making that clear.
I read about user depending rules in IPFW and that one has to disable
mpsafenet, but I'm not using user based rules in my PF config!
Unfortunately this machine is a CF-Card based Router wher I cannot
debug anything, perhaps I can bring a witness-kernel on it, please tell
me if this problem is new to you and if I should do that.
I've CC'd Max Laier due to his extensive work with pf on FreeBSD. I
think a WITNESS+INVARIANTS kenrel would be quite helpful, if you could.
Yes, WITNESS would be interesting, though I don't expect to see any LORs,
as this is not an overly complicated ruleset. Actually, I am very
surprised that it does lock up - what hardware is this?
Resuming work on this, I managed to get a remote console to the box and here's
what I get with today's RELENG_5 and the following command, also I need to
set debug.mpsafenet to 0 otherwise my ruleset doesn't work (do what it should
do and does when set to 0 but not when default 1):
pfctl -F all -f /etc/pf.conf
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xdeadc1d7
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc047ac48
stack pointer = 0x10:0xd0a44728
frame pointer = 0x10:0xd0a44730
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 1053 (sshd)
[thread pid 1053 tid 100081 ]
Stopped at pf_state_compare_lan_ext+0x18: movzbl 0xf9(%esi),%eax
db trace
Tracing pid 1053 tid 100081 td 0xc177e190
pf_state_compare_lan_ext(c176ca00,d0a447d8,d0a44758,c047c095,c176cac0) at
pf_state_compare_lan_ext+0x18
pf_state_tree_lan_ext_RB_FIND(c176cac0,d0a447d8,0,c176ca00,d0a448e4) at
pf_state_tree_lan_ext_RB_FIND+0x29
pf_find_state_recurse(c176ca00,d0a447d8,0,da7a,c0586400) at
pf_find_state_recurse+0x45
pf_test_state_tcp(d0a4492c,2,c176ca00,c1746b00,14) at pf_test_state_tcp+0xb0
pf_test(2,c1586000,d0a44a1c,c19ff168,c1756720) at pf_test+0x981
pf_check_out(0,d0a44a1c,c1586000,2,c19ff168) at pf_check_out+0x4e
pfil_run_hooks(c07f05a0,d0a44aa8,c1586000,2,c19ff168) at pfil_run_hooks+0x15b
ip_output(c1746b00,0,d0a44a74,0,0) at ip_output+0x3ef
tcp_output(c1a02710,c1744900,c076ed93,280,0) at tcp_output+0x984
tcp_usr_send(c1b5fdec,0,c1744900,0,0) at tcp_usr_send+0x239
sosend(c1b5fdec,0,d0a44c84,c1744900,0) at sosend+0x62b
soo_write(c1c5c264,d0a44c84,c1b0f680,0,c177e190) at soo_write+0x49
dofilewrite(5,8081000,a0,,) at dofilewrite+0xac
write(c177e190,d0a44d14,c,431,3) at write+0x77
syscall(2f,2f,2f,8071d88,a0) at syscall+0x137
Xint0x80_syscall() at Xint0x80_syscall+0x1f
--- syscall (4, FreeBSD ELF32, write), eip = 0x282ef73f, esp = 0xbfbfddfc, ebp
=0xbfbfde18 ---
Tell me how I can help, I'll later hand in the trace of the slef-lock when
debug.mpsafenet is 1.
-Harry
What version of FreeBSD are you running? RELENG_5_3? Could you try to
move `src/sys/contrib/pf' to RELENG_5 instead. There are some bugfixes in
there, that might help you. Specificly there was an endless loop in the
state matching code. Please tell me if that helped.
Best regards,
-Harry
pf.conf: (note that the interface names are changed, so fxp0 is SDSL
e.g.)
lan_net=172.23.0.0/16
by_net=192.168.0.0/24
sdsl_net=a.b.c.d/29
sdsl_addr=a.b.c.d
lan_addr=172.23.0.1
#pppoe_addr=10.0.0.1
by_addr=192.168.0.1
proxy=a.a.a.a
mta=b.b.b.b
dns=c.c.c.c
web=d.d.d.d
dns2=10.0.0.2
set block-policy return
scrub in all
nat on SDSL from $lan_net to !$sdsl_net - $sdsl_addr
rdr inet proto tcp from 62.245.232.135 to $sdsl_addr port 3389 -
172.23.2.1 port 3389
block in all
block out all
pass in on lo0 all
pass out on lo0 all
pass in on LAN from $lan_net to any keep state
pass in on SDSL from 62.245.232.135 to any keep state
pass in on SDSL proto tcp from any to $proxy port { 22, 80, 443 } keep
state pass in on SDSL proto tcp from any to $mta port 25 keep state
pass in on SDSL proto { udp, tcp } from any to $dns port 53 keep state
pass in on SDSL proto tcp from any to $web port { 80, 443 } keep state
pass out on SDSL from $sdsl_net keep state
pass out on LAN from $lan_addr to $lan_net keep state
P.S.: Why do I need
PANIC: Re: machine locks with PF (without using user dependent rules)
Am Montag, 7. Februar 2005 16:52 schrieb Emanuel Strobl: Am Samstag, 8. Januar 2005 18:24 schrieb Max Laier: On Saturday 08 January 2005 17:52, Robert Watson wrote: On Sat, 8 Jan 2005, Harald Schmalzbauer wrote: my machine hard locks with the attached ruleset. If I set debug.mpsafenet to 0 everything is fine. This was a wild guess from [...] Tell me how I can help, I'll later hand in the trace of the slef-lock when debug.mpsafenet is 1. Like promised, here it is: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc1d7 fault code = supervisor read, page not present instruction pointer = 0x8:0xc047b518 stack pointer = 0x10:0xcc694954 frame pointer = 0x10:0xcc69495c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 35 (swi1: net) [thread pid 35 tid 100031 ] Stopped at pf_state_compare_ext_gwy+0x18: movzbl 0xf9(%esi),%eax db trace Tracing pid 35 tid 100031 td 0xc1515190 pf_state_compare_ext_gwy(c1748300,cc6949ac,cc694984,c047c0c2,c17483c4) at pf_state_compare_ext_gwy+0x18 pf_state_tree_ext_gwy_RB_FIND(c17483c4,cc6949ac,c1748300,cc694af8,cc694ab8) at pf_state_tree_ext_gwy_RB_FIND+0x29 pf_find_state_recurse(c1748300,cc6949ac,1,c076341c,255) at pf_find_state_recurse+0x72 pf_test_state_udp(cc694b00,1,c1748300,c1856c00,14) at pf_test_state_udp+0x90 pf_test(1,c1585800,cc694bf0,0,c1768720) at pf_test+0xb78 pf_check_in(0,cc694bf0,c1585800,1,0) at pf_check_in+0x48 pfil_run_hooks(c07f05a0,cc694c9c,c1585800,1,0) at pfil_run_hooks+0x15b ip_input(c1856c00,0,c076b16d,e6,c07f0660) at ip_input+0x20f netisr_processqueue(cc694cd8,246,c07c5640,2,c1508d40) at netisr_processqueue+0x15 swi_net(0,0,c075f8fb,269,0) at swi_net+0x8d ithread_loop(c1526300,cc694d48,c075f6d4,31e,0) at ithread_loop+0x1ff fork_exit(c055fcb0,c1526300,cc694d48) at fork_exit+0xa9 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcc694d7c, ebp = 0 --- db -Harry pgpO2GmhMkNt8.pgp Description: PGP signature
interrupt routing
I am preparing a new server for production use. It contains 2 1000BaseTX NICs and 2 SCSI controllers. The interrupt assignment performed by ACPI looks kinda strange: irq24: bge0 ahd0 irq25: bge1 ahd1 How can I affect it? I mean I want all the devices use different IRQ lines. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PANIC: Re: machine locks with PF (without using user dependent rules)
Am Montag, 7. Februar 2005 17:32 schrieb Emanuel Strobl: Am Montag, 7. Februar 2005 16:52 schrieb Emanuel Strobl: Am Samstag, 8. Januar 2005 18:24 schrieb Max Laier: On Saturday 08 January 2005 17:52, Robert Watson wrote: On Sat, 8 Jan 2005, Harald Schmalzbauer wrote: my machine hard locks with the attached ruleset. If I set debug.mpsafenet to 0 everything is fine. This was a wild guess from [...] Tell me how I can help, I'll later hand in the trace of the slef-lock when debug.mpsafenet is 1. Like promised, here it is: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc1d7 fault code = supervisor read, page not present instruction pointer = 0x8:0xc047b518 stack pointer = 0x10:0xcc694954 frame pointer = 0x10:0xcc69495c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 35 (swi1: net) [thread pid 35 tid 100031 ] Stopped at pf_state_compare_ext_gwy+0x18: movzbl 0xf9(%esi),%eax Here's another one: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xc2 fault code = supervisor read, page not present instruction pointer = 0x8:0xc047adcb stack pointer = 0x10:0xcc6975fc frame pointer = 0x10:0xcc697604 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 36 (swi5: clock sio) [thread pid 36 tid 100032 ] Stopped at pf_state_tree_lan_ext_RB_FIND+0xb: movl0(%eax),%ebx db trace Tracing pid 36 tid 100032 td 0xc1515320 pf_state_tree_lan_ext_RB_FIND(c2,cc69788c,0,cc697a20,cc697998) at pf_state_tree_lan_ext_RB_FIND+0xb pf_find_state_recurse(c176c300,cc69788c,0,c08118f4,c1514e20) at pf_find_state_recurse+0x45 pf_test_state_icmp(cc6979ec,2,c176c300,c1743000,30) at pf_test_state_icmp+0xb8 pf_test6(2,c1586000,cc697ac0,0,c17565a0) at pf_test6+0xe30 pf_check6_out(0,cc697ac0,c1586000,2,0) at pf_check6_out+0x35 pfil_run_hooks(c07f3980,cc697b58,c1586000,2,0) at pfil_run_hooks+0x15b ip6_output(c1743000,c07f59c0,cc697bdc,0,cc697c4c) at ip6_output+0xb9a mld6_sendpkt(0,c07a5ab0,c07a59a0,c05af360,cc697ca0) at mld6_sendpkt+0x207 mld6_fasttimeo(c07c5680,1,c0767584,100,6) at mld6_fasttimeo+0x83 pffasttimo(0,8,c076302f,f7,38fd) at pffasttimo+0x85 softclock(0,0,c075f8fb,269,0) at softclock+0x12f ithread_loop(c1526280,cc697d48,c075f6d4,31e,0) at ithread_loop+0x1ff fork_exit(c055fcb0,c1526280,cc697d48) at fork_exit+0xa9 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xcc697d7c, ebp = 0 --- db pgp5TOkXBwQCx.pgp Description: PGP signature
PANIC (maybe pf related?)
Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0xc056cc3c stack pointer = 0x10:0xcc706918 frame pointer = 0x10:0xcc70693c code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 442 (cron) [thread pid 442 tid 100069 ] Stopped at _mtx_lock_flags+0x2c: cmpl$0xc0797f24,0(%ebx) db trace Tracing pid 442 tid 100069 td 0xc158fe10 _mtx_lock_flags(0,0,c075ebf4,768,c176c364) at _mtx_lock_flags+0x2c fdrop(c17a0316,c158fe10,856,8d4,0) at fdrop+0x35 closef(c17a0316,c158fe10,c075ebf4,646,0) at closef+0x32 fdfree(c158fe10,8,c075f5e8,e5,8) at fdfree+0x26b exit1(c158fe10,f,c0762323,9a0,c1794d20) at exit1+0x357 sigexit(c158fe10,f,c0762323,92c,c19c0aa8) at sigexit+0x202 postsig(f,8,c0764e26,100,431) at postsig+0x39b ast(cc706d48) at ast+0x49e doreti_ast() at doreti_ast+0x17 db This happened after reboot -Harry pgpLtnVux52zo.pgp Description: PGP signature
Re: ATA mkIII first official patches - please test!
Sorry to be a BOFH, but could you guys stop crossposting on this topic? I think -current is more suitable for this. Thanks. * Hides in corner * ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 50% of packets lost only on local interfaces
On Mon, Feb 07, 2005 at 11:30:43AM +0100, Jos? M. Fandi?o wrote: Kris Kennaway wrote: On Mon, Feb 07, 2005 at 11:15:52AM +0100, Jos? M. Fandi?o wrote: Jos? M. Fandi?o wrote: Chris wrote: Have tested on 3 boxes. yes, it's the intended operation and If I don't see it I don't believe it but it happens. I ever thought it would be possible. Finally, I found the culprit: CFLAGS= \ 100% of the transmited traffic is received COPTFLAGS= / CFLAGS= -pipe \ 50% of the transmited traffic is received COPTFLAGS= -pipe / That would be exceedingly strange, because the above two options are supposed to produce *no differences at all* with the code generation. I'd believe that -O and no -O could behave differently, although I don't know why you'd want to compile without -O. Actually, the only way I can make sense of this is if CFLAGS= uses the default CFLAGS, which is -O -pipe. Kris pgpDmj6aR8qEu.pgp Description: PGP signature
Re: 50% of packets lost only on local interfaces
José M. Fandiño wrote: Kris Kennaway wrote: On Mon, Feb 07, 2005 at 11:15:52AM +0100, Jos? M. Fandi?o wrote: Jos? M. Fandi?o wrote: Chris wrote: Have tested on 3 boxes. yes, it's the intended operation and If I don't see it I don't believe it but it happens. I ever thought it would be possible. Finally, I found the culprit: CFLAGS= \ 100% of the transmited traffic is received COPTFLAGS= / CFLAGS= -pipe \ 50% of the transmited traffic is received COPTFLAGS= -pipe / That would be exceedingly strange, because the above two options are supposed to produce *no differences at all* with the code generation. I'd believe that -O and no -O could behave differently, although I don't know why you'd want to compile without -O. because by the time I was compiling the system I was no interested in compiler optimizations. Now I prefer a lightly optimized kernel than a system with 50% of packet lost in local interfaces ;-) -O is the default for -STABLE; anything else might very well cause problems. In fact, check out the CFLAGS section of /usr/share/examples/etc/make.conf: Note that optimization settings other than -O and -O2 are not recommended or supported for compiling the world or the kernel - please revert any nonstandard optimization settings to -O before submitting bug reports without patches to the developers. Jon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
ACPI Suspend/resume [was Re: ATA mkIII first official patches...]
Søren Schmidt writes: [...] Find such a machine might be very hard, if not plain impossible :/ I already have 3 laptops here (of which none has worked for several month regarding suspend/resume) so I have plenty. [...] How bad is the acpi suspend/resume situation. I have 5.3-BETA4 on an IBM T42p and suspend to memory and resume work fine. I haven't had time to upgrade (cobbler's kids, no shoes, etc...) but it's on my list of things to do. Does 5.3 Release have a working acpi based suspend/resume for anyone? Does 5-STABLE have a working acpi based suspend/resume for anyone? g. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: pf with debug.mpsafenet
Hello, again I got a panic with PF when debug.mpsafenet is enabled, when set to 0 the machine runs almost fine, except that 'pfctl -F all -f /etc/pf.conf' panics and block return and block return-icmp(3,13) doesn't work. Here's the trace: Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc1d7 fault code = supervisor read, page not present instruction pointer = 0x8:0xc047ac48 stack pointer = 0x10:0xd135e7e8 frame pointer = 0x10:0xd135e7f0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 1156 (sshd) [thread pid 1156 tid 100114 ] Stopped at pf_state_compare_lan_ext+0x18: movzbl 0xf9(%esi),%eax db trace Tracing pid 1156 tid 100114 td 0xc1a24640 pf_state_compare_lan_ext(c1748300,d135e898,d135e818,c047c095,c17483c0) at pf_state_compare_lan_ext+0x18 pf_state_tree_lan_ext_RB_FIND(c17483c0,d135e898,0,c1748300,d135e9a4) at pf_state_tree_lan_ext_RB_FIND+0x29 pf_find_state_recurse(c1748300,d135e898,0,d135e880,d135e840) at pf_find_state_recurse+0x45 pf_test_state_tcp(d135e9ec,2,c1748300,c1745000,14) at pf_test_state_tcp+0xb0 pf_test(2,c1585800,d135eadc,c19ccbf4,c19d4000) at pf_test+0x981 pf_check_out(0,d135eadc,c1585800,2,c19ccbf4) at pf_check_out+0x4e pfil_run_hooks(c07f05a0,d135eb68,c1585800,2,c19ccbf4) at pfil_run_hooks+0x15b ip_output(c1745000,0,d135eb34,0,0) at ip_output+0x3ef tcp_output(c1b7e1c4,8,c076ed93,169,c1ce2654) at tcp_output+0x984 tcp_usr_connect(c1ce2654,c1696b40,c1a24640) at tcp_usr_connect+0xbc soconnect(c1ce2654,c1696b40,c1a24640,10,c05bb4d8) at soconnect+0x5a kern_connect(c1a24640,b,c1696b40,c1696b40) at kern_connect+0x9a connect(c1a24640,d135ed14,c,431,3) at connect+0x48 syscall(807002f,807002f,bfbf002f,807b6c0,b) at syscall+0x137 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (98, FreeBSD ELF32, connect), eip = 0x282eeedf, esp = 0xbfbfd8cc, ebp = 0xbfbfdd78 --- db Let me know if I can test anything for you. -Harry pgpbjVbXZsb9D.pgp Description: PGP signature
Re: 50% of packets lost only on local interfaces
José M. Fandiño wrote: Jon Noack wrote: Finally, I found the culprit: CFLAGS= \ 100% of the transmited traffic is received COPTFLAGS= / CFLAGS= -pipe \ 50% of the transmited traffic is received COPTFLAGS= -pipe / That would be exceedingly strange, because the above two options are supposed to produce *no differences at all* with the code generation. I'd believe that -O and no -O could behave differently, although I don't know why you'd want to compile without -O. because by the time I was compiling the system I was no interested in compiler optimizations. Now I prefer a lightly optimized kernel than a system with 50% of packet lost in local interfaces ;-) -O is the default for -STABLE; anything else might very well cause problems. In fact, check out the CFLAGS section of /usr/share/examples/etc/make.conf: Note that optimization settings other than -O and -O2 are not recommended or supported for compiling the world or the kernel - please revert any nonstandard optimization settings to -O before submitting bug reports without patches to the developers. I think this comment was referring to higher optimizations levels than -O2, anyway removing -O shouldn't be so harmful. The explanation I've heard (I have no actual knowledge here, I'm just good at repeating others) is that gcc doesn't compile any ASM with -O0 (which is what you get with CFLAGS=-pipe). This Breaks Things(tm): http://docs.freebsd.org/cgi/mid.cgi?20020623214947.J84322 kern/52764 is another example: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/52764 More generically it makes sense that gcc treat code differently with -O0 than with -O. With the vast majority of users using -O and different code paths being taken with -O0, it doesn't surprise me at all that there are issues. It should be assumed that nonstandard means exactly what it says: something other than -O (or more recently -O2). If it breaks, try -O. If it's still broken with -O, report away. Regards, Jon P.S. Historically, the reason to use -O0 was for easier debugging. It appears that steps have been taken to ease debugging with -O to the point that it is no longer necessary to use -O0 (with the FreeBSD kernel and world, at least); I don't recall a FreeBSD developer ever asking someone to recompile with -O0 to help solve a problem... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI Suspend/resume [was Re: ATA mkIII first official patches...]
George Hartzell wrote: I haven't had time to upgrade (cobbler's kids, no shoes, etc...) but it's on my list of things to do. Does 5.3 Release have a working acpi based suspend/resume for anyone? Does 5-STABLE have a working acpi based suspend/resume for anyone? Suspend to memory works on my T42 on 5.3-STABLE as of 1/1/05. except i've got to restart mosed. I've not bothered to investigate what's going on. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI Suspend/resume [was Re: ATA mkIII first official patches...]
Date: Mon, 07 Feb 2005 18:17:16 -0500 From: David Scheidt [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] George Hartzell wrote: I haven't had time to upgrade (cobbler's kids, no shoes, etc...) but it's on my list of things to do. Does 5.3 Release have a working acpi based suspend/resume for anyone? Does 5-STABLE have a working acpi based suspend/resume for anyone? Suspend to memory works on my T42 on 5.3-STABLE as of 1/1/05. except i've got to restart mosed. I've not bothered to investigate what's going on. Add hint.psm.0.flags=0x2000 or hint.psm.0.flags=0x6000 to your /boot/device.hints. Try 0x2000 first as it is less extreme. If that does not fix it, try 0x6000. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: strange make problem with non root users 5.3-STABLE
# [EMAIL PROTECTED] / 2005-02-03 22:16:58 +: have a look at this compiling a eggdrop had the same with some other apps as well. [EMAIL PROTECTED] eggdrop1.6.17 # make config make: Permission denied [EMAIL PROTECTED] eggdrop1.6.17 # make config make: Permission denied [EMAIL PROTECTED] eggdrop1.6.17 # cd .. [EMAIL PROTECTED] Gazzeh # cd eggdrop1.6.17 [EMAIL PROTECTED] eggdrop1.6.17 # make config Detecting modules done. Calculating dependencies... done. Building ./src/mod/Makefile... done. You are misuising the system. What's your $PWD in the dir where you run make config? It should be /usr/ports/category/port/, *not* /usr/ports/category/port/work/whatever/! Oh, and BTW, the error message you got was most probably caused by your $PWD being in a directory that has been rm'd from under your feet and then recreated. -- FreeBSD 4.10-STABLE 12:32AM up 16:32, 5 users, load averages: 0.00, 0.02, 0.00 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.x concerns
On Sun, Feb 06, 2005 at 03:01:49PM +, Chris wrote: 4 - compatiblity, I remember using 5.2.1 and pretty much all software worked well in that and then they did the bind defaulting to base and libs version jump, why wasnt this done in 5.0 so 3rd party apps could adjust, now we have a situation where most stuff that worked in 4.x worked well in 5.1 and 5.2.1 but then broke in 5.3 so effectively 5.3 was liek a new major version over 5.2.1. 5.2.1 was clearly marked as a developer preview release and you were warned not to rely on it for production use. As a snapshot of FreeBSD-CURRENT, binary compatibility is not guaranteed and often needs to be broken in the course of development. Kris Just adding a note: I regularly use FreeBSD on a Toshiba notebook, and switched from 4.x to 5.x to benefit from cardbus support. Well, I started with 5.2.1 and all things did well. Since then, I'm trying to track 5-STABLE with no success. Starting with 5.3-RELEASE, the ACPI stopped to work, as well as did the rl driver. So, I switched back to 5.2.1. []s Tórgan___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.x concerns
On February 7, 2005 03:40 pm, Tórgan Flores de Siqueira wrote: Just adding a note: I regularly use FreeBSD on a Toshiba notebook, and switched from 4.x to 5.x to benefit from cardbus support. Well, I started with 5.2.1 and all things did well. Since then, I'm trying to track 5-STABLE with no success. Starting with 5.3-RELEASE, the ACPI stopped to work, as well as did the rl driver. So, I switched back to 5.2.1. What model Toshiba laptop are you using? I'm curious as I have a Toshiba Satellite A60 that works quite nicely with FreeBSD 5.2.1, 5.3, and 6-CURRENT (with the exception of the WinModem and soundcard not working, and the ATA controllers only being recognised as UDMA33). The NIC works, the wireless NIC works, the CPU throttling works, the video card works perfectly in 2D and provides software 3D support (there's no AGP module for the ATI Radeon 7000 IGP chipset). Even the USB 2.0 ports work. 5.2-CURRENT had working sleep/resume support, but then it disappeared one day, and I was never able to track down if it was a BIOS update, ACPI update, or driver update that killed it. Not that it bothers me, I prefer to power it off completely anyway. -- Freddie Cash, CCNT CCLPHelpdesk / Network Support Tech. School District 73 (250) 377-HELP [377-4357] [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.x concerns
On Mon, Feb 07, 2005 at 09:40:48PM -0200, T?rgan Flores de Siqueira wrote: On Sun, Feb 06, 2005 at 03:01:49PM +, Chris wrote: 4 - compatiblity, I remember using 5.2.1 and pretty much all software worked well in that and then they did the bind defaulting to base and libs version jump, why wasnt this done in 5.0 so 3rd party apps could adjust, now we have a situation where most stuff that worked in 4.x worked well in 5.1 and 5.2.1 but then broke in 5.3 so effectively 5.3 was liek a new major version over 5.2.1. 5.2.1 was clearly marked as a developer preview release and you were warned not to rely on it for production use. As a snapshot of FreeBSD-CURRENT, binary compatibility is not guaranteed and often needs to be broken in the course of development. Kris Just adding a note: I regularly use FreeBSD on a Toshiba notebook, and switched from 4.x to 5.x to benefit from cardbus support. Well, I started with 5.2.1 and all things did well. Since then, I'm trying to track 5-STABLE with no success. Starting with 5.3-RELEASE, the ACPI stopped to work, as well as did the rl driver. So, I switched back to 5.2.1. Sorry to hear that - I hope you submitted bug reports so that someone can try to fix this, otherwise you might be stuck with 5.2.1 forever. Kris pgp8wNVXtEuqB.pgp Description: PGP signature
Re: writeprotected floppy not unmountable on STABLE
On Sun, 30 Jan 2005, Oliver Lehmann wrote: Hi, I mounted a write-pretected floppy on 5-STABLE and now I'm not able to unmount the floppy For the record I can reproduce this. There is #ifdef notyet'd code in fdc that would avoid this case. I'm hoping phk can explain what changes are still necessary to activate that code. It appears some GEOM knowledge needs to make it into the filesystems on RELENG_5. Since the code is active in HEAD it shouldn't allow mounting RO floppies. [EMAIL PROTECTED] /root mount_msdosfs /dev/fd0 /mnt/tmp [EMAIL PROTECTED] /root touch /mnt/tmp/test touch: /mnt/tmp/test: Read-only file system Exit 1 [EMAIL PROTECTED] /root mount /dev/ad0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad0s1e on /tmp (ufs, local, soft-updates) /dev/ad0s1f on /usr (ufs, local, soft-updates) /dev/ad0s1d on /var (ufs, local, soft-updates) /dev/ad0s3e on /usr/home (ufs, local, soft-updates) /dev/ad0s4e on /mnt/movies (ufs, local, soft-updates) file:/usr/ports on /usr/ports (nfs) file:/usr/src on /usr/src (nfs) file:/mnt/backups on /mnt/backups (nfs) file:/mnt/documents on /mnt/documents (nfs) file:/mnt/files on /mnt/files (nfs) www:/usr/local/www on /mnt/www (nfs) /dev/fd0 on /mnt/tmp (msdosfs, local) [EMAIL PROTECTED] /root umount /mnt/tmp umount: unmount of /mnt/tmp failed: Resource temporarily unavailable Exit 1 [EMAIL PROTECTED] /root what works is [EMAIL PROTECTED] /root umount -f /mnt/tmp [EMAIL PROTECTED] /root CURRENT correctly detects that the floppy is write-protected, and fails to mount it unless -o ro is specified. umount on CURRENT is also possible. [EMAIL PROTECTED] /root uname -a FreeBSD kartoffel.salatschuessel.net 5.3-STABLE FreeBSD 5.3-STABLE #0: Sun Jan 16 15:35:29 CET 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/KARTOFFEL i386 please keep me CCed - I'm not subscribed -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: interrupt routing
On Mon, 7 Feb 2005, dima wrote: I am preparing a new server for production use. It contains 2 1000BaseTX NICs and 2 SCSI controllers. The interrupt assignment performed by ACPI looks kinda strange: irq24: bge0 ahd0 irq25: bge1 ahd1 How can I affect it? I mean I want all the devices use different IRQ lines. What hardware, curiously? Are all of these parts onboard? Can you post the ouptut of 'devconf'? This will show the bus associations for these devices. In many cases there are not other IRQs available to route, due to poor BIOS programming, ccorners cut in the physical board layout, etc. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA mkIII first official patches - please test!
Søren Schmidt [EMAIL PROTECTED] writes: http://people.freebsd.org/~sos/ata-mk3j.diff-releng5.gz http://people.freebsd.org/~sos/ata-mk3j.diff-current.gz http://people.freebsd.org/~sos/ata-mk3j.tar.gz sys/dev/ata/ata-all.c rev 1.235 conflicts, could you please update the -CURRENT patch? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATA mkIII first official patches - please test!
Dag-Erling Smørgrav wrote: Søren Schmidt [EMAIL PROTECTED] writes: http://people.freebsd.org/~sos/ata-mk3j.diff-releng5.gz http://people.freebsd.org/~sos/ata-mk3j.diff-current.gz http://people.freebsd.org/~sos/ata-mk3j.tar.gz sys/dev/ata/ata-all.c rev 1.235 conflicts, could you please update the -CURRENT patch? There is no patch for ata-all.c there is a replacement. I will eventually get that updated (so you can run cvs diff ?)... -- -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI Suspend/resume [was Re: ATA mkIII first official patches...]
Hi, Does 5-STABLE have a working acpi based suspend/resume for anyone? I have a 5-STABLE from 27.01, on an IBM R40e. Suspend to memory (-s 3) seems to work, but there is no way to resume. How do you trigger a resume?? CU, Vlad ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
