[releng_8_0 tinderbox] failure on amd64/amd64

[FreeBSD Tinderbox]

TB --- 2010-07-28 08:04:01 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-07-28 08:04:01 - starting RELENG_8_0 tinderbox run for amd64/amd64
TB --- 2010-07-28 08:04:01 - cleaning the object tree
TB --- 2010-07-28 08:04:26 - cvsupping the source tree
TB --- 2010-07-28 08:04:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/RELENG_8_0/amd64/amd64/supfile
TB --- 2010-07-28 08:41:44 - WARNING: /usr/bin/csup returned exit code  1 
TB --- 2010-07-28 08:41:44 - ERROR: unable to cvsup the source tree
TB --- 2010-07-28 08:41:44 - 0.90 user 12.84 system 2262.79 real


http://tinderbox.freebsd.org/tinderbox-releng_8-RELENG_8_0-amd64-amd64.full
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: possible regression - rum ap problem under 8.1R

[Michael Proto]

On Tue, Jul 27, 2010 at 6:06 PM, Nenhum_de_Nos  wrote:
> hail,
>
> I have a small mini itx, crusoe based, and it was running pfSense 1.2.3R
> (FreeBSD 7.2). there was an ap using tp-link tl-wn321 usb adapter. no
> problems. I then installed 8.1R and tried the same config, and got kernel
> panic. Installed 7.2R (no patches applied) and it is working.
>
> the only info is that 7.2R does not load acpi, but I tried this on 8.1R to
> no avail. with acpi 7.2R would not use my integrated nic.
>
> it complaints about no dump device and I imagine there is no dump.
>
> is this known ?
> what info can I get to help ?
>
...
> on 8.1R:
>
> wlans_rum0="wlan0"
> ifconfig_wlan0="inet 192.168.12.254"
> create_args_wlan0="wlanmode ap ssid rush"
> hostapd_enable="YES"
>
> the hostapd.conf is the same, just change wlan0 to rum0. both load
> wlan_ccmp and wlan_xauth on boot.
>
> thanks,

You might want to add the following to rc.conf:

ifconfig_rum0="up"



-Proto
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

zfs boot issue with and without AHCI

[Mike Tancsa]

I followed the very helpful docs at
https://www.dan.me.uk/blog/2010/02/08/booting-from-zfs-raid056-in-freebsd-8-0-release/ 



to get an 8.1R AMD64 install working booting purely off a zfs 
mirror!  However, one small issue I ran into is with AHCI enabled in the BIOS.


I did the install directly to disks ada0 and ada1 as I loaded AHCI 
from the boot DVD's loader prompt.  Everything booted up great.


http://www.tancsa.com/zfs/ahci-boot.txt 



Then, I took out the DVD ROM drive (CD1) that I installed from and 
went to reboot.  This time, the box would insta reboot just after the 
'BTX Loader' text would appear.  I then put back the DVD ROM and 
rebooted, still the same problem. Then, I went into the BIOS and 
forced the DVD to be the first boot device, just like it was at 
install time... Everything booted up fine once again.?!?!


Then, I pulled the DVD drive and  I rebooted the box and disabled 
AHCI in the BIOS and used just regular enhanced mode, and all booted 
up just fine.


http://www.tancsa.com/zfs/ata-boot.txt 



Is there something additionally that needs to be set for ahci to work 
in this manner ?


---Mike



Mike Tancsa,  tel +1 519 651 3400
Sentex Communications,m...@sentex.net
Providing Internet since 1994www.sentex.net
Cambridge, Ontario Canada www.sentex.net/mike

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: SIGEPIPE after update to 8.1-RC2

[Kostik Belousov]

On Sun, Jul 25, 2010 at 01:48:16PM +0200, Jilles Tjoelker wrote:
> On Sun, Jul 18, 2010 at 12:20:33PM +1000, Sean wrote:
> > I'm getting the same thing; what shell are you using? I changed my shell 
> > on one machine from /bin/tcsh to /usr/local/bin/bash and problem 
> > disappeared.
> 
> That this workaround helps confirms that masked/ignored SIGPIPE is the
> problem. From a few shells I have tried, bash and zsh reset SIGPIPE to
> caught or default even if it was ignored (only in interactive mode,
> however), while tcsh, sh, mksh and ksh93 leave it ignored.
> 
> The underlying problem is the program that is passing the ignored/masked
> signal to child processes. Please check if the problem occurs with
> various ways to log in (text console, ssh, xterm, etc). Things like PAM
> modules may also cause problems here.
> 
> For example, sshd sets SIGPIPE to ignored, but resets it back to default
> before starting a child process, so assuming I read the code correctly
> it does not cause problems.

Hm.

pooma% cat
...
In the other shell,
pooma% ps auxww | grep cat
kostik 41346  0.0  0.0  5824  1084   2  I+   11:34PM   0:00.00 cat
pooma% procstat -i 41346 | grep PIPE
41346 cat  PIPE ---


pooma% sudo cat
...
and
pooma% ps auxww | grep cat
root   41360  0.0  0.0  5824  1084   2  S+   11:36PM   0:00.01 cat
pooma% procstat -i 41366 | grep PIPE
41366 cat  PIPE ---

And now
oma% sudo -k cat~
Password:
...
and
pooma% ps auxww | grep cat
root   41387  0.0  0.0  5824  1084   2  S+   11:39PM   0:00.01 cat
pooma% procstat -i 41387 | grep PIPE
41387 cat  PIPE -I-

This would describe both the observed behaviour and the reason why
I was unable to repeat it after the first run.

sudo changelog has a promising entry from 2010-06-09, but I definitely
not going to read sudo code. security/sudo maintainer Cc:ed.


pgpyabP7aBJrj.pgp
Description: PGP signature

Re: 8.x grudges

[Mikhail T.]

09.07.2010 05:49, Peter Jeremy ???(??):

I doubt I'm personally in a position to debug this and don't personally
use splash screens.  Can you reproduce it using an image that you can
re-distribute?
   
Ok, the splash-screen problem went away after I put back the original 
video-card. The one I tried with (a high-end, but old) worked fine in 
text mode, but, apparently, had issues in the graphical mode... Retracted...

3. Likewise, having "device ugen" breaks config(8) -- another
   undocumented incompatibility.
 

It was a valid device for FreeBSD-7. The UPDATING-file enumerates a
number of things, that need to be changed, when updating to 8, but the
removal of "ugen" is not mentioned there.
 

Well, the definitive list is sys/conf/NOTES and sys/$(uname -m)/conf/NOTES
   
The "NOTES" files are code, not documentation... If the "UPDATING" file 
did not exist, I'd be looking elsewhere for the changes. But it does 
exist and so should be complete (perhaps, it should be auto-generated 
based on the commit-history of the NOTES and GENERIC kernel-configs?)

but I agree that the ugen(4) man page is incorrect and a case could be
made for having better details of USB2 in UPDATING.
I did not even realize, the ugen(4) still exists in 8.1 (and would've 
thought, it was a remnant from 7.x), if I saw it. My "grudge" was that 
the "UPDATING" file did not tell me about neither it, nor about the sio 
being broken.

How would you like to write up patches and submit a PR?
   
I have some -- much more involved -- patches sitting in the PR database 
for years, so, pardon me for not accepting your invitation to file more 
at this time... The ones most ripe for committing are:


   * handle SIGINFO in sleep(1)
  -- recent
   * pkg_add(1) pkg-routines ignore the recorded md5 checksums
  -- 8 years old
   * bikeshed entry of Handbook is wrong
  -- a
 doc-one, 5 years old now, still valid...

Search the PR-db for others, where a dialog/discussion might be 
necessary -- the above ones are only those completely ready...

That's why I asked for the output up to the hang - which might show
where the problem is.  If you don't have a serial console, take a
photo and put it up on the web.
   
Ok, here is the screen-shot 
 (firewire 
enabled in BIOS). Hanging while probing USB-devices...



BTW, in all writing you've done, you've never mentioned what FreeBSD
version you are running beyond a vague "8.1 prerelease", what motherboard
you have (despite my request for this) and only indirectly given the
architecture (via the config file you posted).
   
Well, the version was also implied -- 8.1/prerelease as of 
(approximately) the date of the posting. The motherboard version -- I'm 
not sure still. Something like nVidia nForce2 -- does that identify it 
enough? The verbose dmesg.boots are:


   * 7.3-PRERELEASE Feb 5
 
 (firewire enabled -- no hang. This is one extracted from
 /var/log/messages and is a little garbled.)
   * 8.1-PRERELEASE July 5
 
 (firewire disabled -- otherwise hangs)
   * 8.1-PRERELEASE July 14
 
 (firewire disabled. Interestingly, the July 14th version reports
 slightly different memory "base")

Yours,

   -mi

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: possible regression - rum ap problem under 8.1R

[Nenhum_de_Nos]

On Wed, July 28, 2010 15:42, Michael Proto wrote:
> On Tue, Jul 27, 2010 at 6:06 PM, Nenhum_de_Nos 
> wrote:
>> hail,
>>
>> I have a small mini itx, crusoe based, and it was running pfSense 1.2.3R
>> (FreeBSD 7.2). there was an ap using tp-link tl-wn321 usb adapter. no
>> problems. I then installed 8.1R and tried the same config, and got
>> kernel
>> panic. Installed 7.2R (no patches applied) and it is working.
>>
>> the only info is that 7.2R does not load acpi, but I tried this on 8.1R
>> to
>> no avail. with acpi 7.2R would not use my integrated nic.
>>
>> it complaints about no dump device and I imagine there is no dump.
>>
>> is this known ?
>> what info can I get to help ?
>>
> ...
>> on 8.1R:
>>
>> wlans_rum0="wlan0"
>> ifconfig_wlan0="inet 192.168.12.254"
>> create_args_wlan0="wlanmode ap ssid rush"
>> hostapd_enable="YES"
>>
>> the hostapd.conf is the same, just change wlan0 to rum0. both load
>> wlan_ccmp and wlan_xauth on boot.
>>
>> thanks,
>
> You might want to add the following to rc.conf:
>
> ifconfig_rum0="up"

I config all using an ap.sh script where this line lies in.

I'm now trying it on newest pfsense 8.1 based snapshot.

thanks,

matheus

-- 
We will call you cygnus,
The God of balance you shall be

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

http://en.wikipedia.org/wiki/Posting_style
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: possible regression - rum ap problem under 8.1R

[Nenhum_de_Nos]

On Wed, July 28, 2010 18:29, Nenhum_de_Nos wrote:
>
> On Wed, July 28, 2010 15:42, Michael Proto wrote:
>> On Tue, Jul 27, 2010 at 6:06 PM, Nenhum_de_Nos
>> 
>> wrote:
>>> hail,
>>>
>>> I have a small mini itx, crusoe based, and it was running pfSense
>>> 1.2.3R
>>> (FreeBSD 7.2). there was an ap using tp-link tl-wn321 usb adapter. no
>>> problems. I then installed 8.1R and tried the same config, and got
>>> kernel
>>> panic. Installed 7.2R (no patches applied) and it is working.
>>>
>>> the only info is that 7.2R does not load acpi, but I tried this on 8.1R
>>> to
>>> no avail. with acpi 7.2R would not use my integrated nic.
>>>
>>> it complaints about no dump device and I imagine there is no dump.
>>>
>>> is this known ?
>>> what info can I get to help ?
>>>
>> ...
>>> on 8.1R:
>>>
>>> wlans_rum0="wlan0"
>>> ifconfig_wlan0="inet 192.168.12.254"
>>> create_args_wlan0="wlanmode ap ssid rush"
>>> hostapd_enable="YES"
>>>
>>> the hostapd.conf is the same, just change wlan0 to rum0. both load
>>> wlan_ccmp and wlan_xauth on boot.
>>>
>>> thanks,
>>
>> You might want to add the following to rc.conf:
>>
>> ifconfig_rum0="up"
>
> I config all using an ap.sh script where this line lies in.
>
> I'm now trying it on newest pfsense 8.1 based snapshot.
>
> thanks,
>
> matheus

for the record, pfSense from 27/07/2010 get me in the same place (I did
see that coming ... as is 8.1-RC2). the error in the screen is:

Fatal trap 18: integer divide dault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0xc08bc42e
stack pointer   = 0x28:0xe32479ac
frame pointer   = 0x28:0xe32479bc
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 = 28706 (hostapd)
trap number = 18
panic: integer devide fault
cpuid =0

just to be clear, I can make the ap and my notebook sees the network fine.
this just happens when I try to connect to it. tried sometimes for now,
and all of them got me this.

thanks,

matheus


-- 
We will call you cygnus,
The God of balance you shall be

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

http://en.wikipedia.org/wiki/Posting_style
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 8.x grudges

[Stefan Lambrev]

Hi,

On Jul 28, 2010, at 11:41 PM, Mikhail T. wrote:

> 09.07.2010 05:49, Peter Jeremy ???(??):
>> I doubt I'm personally in a position to debug this and don't personally
>> use splash screens.  Can you reproduce it using an image that you can
>> re-distribute?
>>   
> Ok, the splash-screen problem went away after I put back the original 
> video-card. The one I tried with (a high-end, but old) worked fine in text 
> mode, but, apparently, had issues in the graphical mode... Retracted...
>3. Likewise, having "device ugen" breaks config(8) -- another
>   undocumented incompatibility.
> 
>>> It was a valid device for FreeBSD-7. The UPDATING-file enumerates a
>>> number of things, that need to be changed, when updating to 8, but the
>>> removal of "ugen" is not mentioned there.
>>> 
>> Well, the definitive list is sys/conf/NOTES and sys/$(uname -m)/conf/NOTES
>>   
> The "NOTES" files are code, not documentation... If the "UPDATING" file did 
> not exist, I'd be looking elsewhere for the changes. But it does exist and so 
> should be complete (perhaps, it should be auto-generated based on the 
> commit-history of the NOTES and GENERIC kernel-configs?)

http://www.freebsd.org/doc/handbook/kernelconfig-config.html :
 For an exhaustive list of architecture dependent options and devices, see the 
NOTES file in the same directory as the GENERIC file. For architecture 
independent options, see /usr/src/sys/conf/NOTES.

I duno if this is documentation or not .. the handbook states that this is a 
list :)

Also I'm pretty sure there was an entry for the USB changes in UPDATING:

20090223:
The new USB2 stack has now been permanently moved in and all kernel and
module names reverted to their previous values (eg, usb, ehci, ohci,
ums, ...).  The old usb stack can be compiled in by prefixing the name
with the letter 'o', the old usb modules have been removed.
Updating entry 20090216 for xorg and 20090215 for libmap may still
apply.


There was a huge change for the GENERIC at this date (+29 -88 lines) so it's 
doesn't sound correct to
document verbosely all of them in UPDATING.

-cut- 

--
Best Wishes,
Stefan Lambrev
ICQ# 24134177





___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

ath(4) hostap with fake MAC/BSSID results in station dropping packets when associated

[Martin]

Hi,

I noticed a bug that was introduced somewhere in the Atheros 9280
support in 8.1-RELEASE when used as a station. I had this already
running correctly with 7.x releases.

What happens:

I cannot connect to a hostap ath(4) (Atheros 2413) when using a fake
MAC/BSSID (on the hostap!).

How to reproduce it:

1) Put this into your rc.local on your hostap machine and replace xx's
by an address of your choice (first octet needs to have lowest bit "0"):

ifconfig ath0 ether xx:xx:xx:xx:xx:xx

2) Start hostapd (must be configured, of course). Eventually you need
to set BSSID also in hostapd.conf.

3) Try to connect with an Atheros 9280. You don't need to fake MAC
address here (I'm only talking about the hostap MAC/BSSID).

What you get:

- You get association. This is OK, so far.
- Try DHCP. You won't see packets arriving at the station. They are not
  recognized and filtered somewhere.
- When you watch with tcpdump on the hostap interface you'll see DHCP
  requests arriving and being answered.
- I further noticed, even you don't have any IP (set to 0.0.0.0,
  because of failed DHCP), you can see packets being sent to different
  machines
- You can try to setup a static address, but when you ping the station,
  you don't see a ping arriving (watch tcpdump on the station wireless
  interface and try to ping from the hostap machine).

Further information:

- This only affects ath(4) and I could only see this on Atheros 9280,
  because I don't have any other ath(4) adapters at the moment.
- I tried rum(4). It does not have any problems like this. DHCP and
  everything else works with this driver (of course with a fake
  MAC/BSSID!).
- Running 8.1-RELEASE on all machines. Kernel is GENERIC, but on hostap
  machine there is ALTQ added (should not affect anything, as I said,
  I had this running already).
- hostapd is configured with 11g, WPA2 and passwords in hostapd.wpapsk.
  WME is switched off, because it does not work at all for me.

I can provide more information, if needed.

--
Martin
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 8.1 stable ar9285 ath0 problem

[Troye Johnson]

UPDATE: I contacted the driver author and he said that the message, "kernel:
ath0: bb hang detected, resetting," means that the hardware is hung, and the
kernel attempted to reset the hardware device (in this case the wifi chip).
So, basically there is a bug in the driver. On 8.1 stable release the
hardware notes say that Atheros AR9285 is supported by the kernel. I'm
willing to test OR donate (preferably lend) my Asus EEE 1005HA machine for
the cause.

---

Proud N00b!
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: 8.1 stable ar9285 ath0 problem

[Troye Johnson]

UPDATE: Oh, one more thing. Upon loading the ath driver a couple of days ago
I got a kernel panic and freeze. It panicked and then the system froze. The
driver can scan for access points and associates to the AP, but then the
kernl delivers the message in /var/log/message ("kernel: ath0: bb hang
detected, resetting) that the ath driver froze.

---

Proud N00b
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Atheros AR9280 on 8.1-RC2 - unusable

[Troye Johnson]

Well good news. There is already a problem report out on this issue. R.
Paulo has been paged and hopefully he will fix this. I'll send $10 to the
first person who gets the ar9285 stable under FBSD. Comment in pr to claim
prize.

pr:kern/148112
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"